As we reported in earlier blog posts, the threat actor NOBELIUM recently intensified an email-based attack that it has been operating and evolving since early 2021. We continue to monitor this active attack and intend to post additional details as they become available. In this blog, we highlight four tools representing a unique infection chain utilized by NOBELIUM: EnvyScout, BoomBox, NativeZone, and VaporRage. These tools have been observed being used in the wild as early as February 2021, attempting to gain a foothold on a variety of sensitive diplomatic and government entities.
As part of this blog, Microsoft Threat Intelligence Center (MSTIC) is releasing an appendix of indicators of compromise (IOCs) for the community to better investigate and understand NOBELIUM’s most recent operations.
Note: The NOBELIUM indicators of compromise (IOCs) associated with this activity are available in CSV on the MSTIC GitHub.
Update [06/01/2021]: We updated the NOBELIUM IOCs to include MD5 hashes.
This sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get the latest information and guidance from Microsoft at https://aka.ms/nobelium. We have also outlined related alerts in Microsoft 365 Defender, so that security teams can check to see if activity has been flagged for investigation.
Each of the NOBELIUM tools discussed in this blog is designed for flexibility, enabling the actor to adapt to operational challenges over time. While its technical specifics are not unprecedented, NOBELIUM’s operational security priorities have likely influenced the design of this toolset, which demonstrate preferable features for an actor operating in potentially high-risk and high-visibility environments. These attacker security priorities are:
NOBELIUM is an actor that operates with rapid operational tempo, often leveraging temporary infrastructure, payloads, and methods to obfuscate their activities. We suspect that NOBELIUM can draw from significant operational resources that are often showcased in their periodic campaigns. Since December, the security community has identified a growing collection of payloads attributed to the actor, including the GoldMax, GoldFinder, and Sibot malware identified by Microsoft, as well as TEARDROP (FireEye), SUNSPOT (CrowdStrike), Raindrop (Symantec) and, most recently, FLIPFLOP (Volexity).
Despite growing community visibility since the exposure of the SolarWinds attack in late 2020, NOBELIUM has continued to target government and diplomatic entities across the globe. We anticipate that as these operations progress, NOBELIUM will continue to mature their tools and tactics to target a global audience.
While this post focuses on a single wave of the campaign comprised of the mentioned four malware families, it also highlights variations in the campaign wherein methodologies were altered per wave. The list of indicators in the appendix expands beyond this single wave.
NV.html, tracked by Microsoft as EnvyScout, can be best described as a malicious dropper capable of de-obfuscating and writing a malicious ISO file to disk. EnvyScout is chiefly delivered to targets of NOBELIUM by way of an attachment to spear-phishing emails.
The HTML <body> section of NV.html contains four notable components:
Component #1: Tracking and credential-harvesting URLs
In one variant of EnvyScout, the <body> section contains two URLs, as shown above.
The first, prefixed with a file:// protocol handler, is indicative of an attempt to coax the operating system to send sensitive NTLMv2 material to the specified actor-controlled IP address over port 445. It is likely that the attacker is running a credential capturing service, such as Responder, at the other end of these transactions. Later, brute-forcing of these credentials may result in their exposure.
The second URL, which resolves to the same IP address as the former at the time of analysis, remotely sources an image that is part of the HTML lure. This technique, sometimes referred to as a “web bug”, serves as a read receipt of sorts to NOBELIUM, validating that the prospective target followed through with opening the malicious attachment.
Component #2: FileSaver JavaScript helper code
The second portion of EnvyScout is a modified version of the open-source tool FileSaver, which is intended to assist in the writing of files to disk via JavaScript. The code is borrowed directly from the publicly available variants with minor alterations, including whitespace removal, conversion of hex parameters to decimal, and renamed variables. By combining this code with components #3 and #4 detailed below, NOBELIUM effectively implements a methodology known as HTML smuggling. This methodology may circumvent static analysis of known malicious file types by obscuring them within dynamically altered content upon execution. When combined with dynamic analysis guardrails, this can be an effective way to subvert detections of both types.
Component #3: Obfuscated ISO file
The third section of EnvyScout contains a payload stored as an encoded blob. This payload is decoded by XOR’ng each character with a single-byte key, which then leads to a Base64 payload that is then decoded and written to disk via components #2 and #4.
Component #4: De-obfuscator and dropper script
The final component of EnvyScout is a short code snippet responsible for decoding the ISO in the Base64 encoded/XOR’d blob, and saving it to disk as NV.img with a mime type of “application/octet-stream”. At this stage of infection, the user is expected to open the downloaded ISO, NV.img, by double clicking it.
As Microsoft has been tracking waves of this campaign for months, we have identified various modifications to the actor’s toolkit that were not present in every instance of EnvyScount but are nonetheless notable for defenders:
EnvyScout variation #1:
In some iterations of the actor’s phishing campaigns, EnvyScout contained execution guardrails wherein window.location.pathname was called, and its values were leveraged to ensure that the first two entries in the array of characters returned were “C” and “:”. If this condition was not met—indicating the sample was not being executed from the C: drive—the embedded ISO was not written to disk.
As the attacker had gathered qualities from detonations of previous entries in the campaign via the Firebase fingerprinting JavaScript detailed in a prior blog post, this was assessed to be an execution guardrail to deter analysis and dynamic execution of the samples bearing these guardrails. Having witnessed both iterations of EnvyScout in the wild allows us to infer the intent of some of the information gathered from earlier instances.
EnvyScout variation #2:
In at least one instance of EnvyScout delivery, we observed further enumeration of the executing browser’s environment, wherein the user-agent was used to determine whether a Windows machine received an ISO payload. If the visitor arrived via iOS, they were redirected to external infrastructure.
When a target user opens NV.img (dropped by EnvyScout) by double-clicking it, the default behavior on Windows 10 is to mount the ISO image at the next available drive letter. Windows Explorer subsequently displays the contents of the mounted ISO in a window, similar to what users see when they open folders or compressed archives.
As shown above, the mounted ISO contains a single visible file, a shortcut file named NV. However, adjusting the file and folder settings in Windows to show hidden files and folders exposes a hidden folder named NV and a hidden executable named BOOM.exe:
The user is likely expected to interact with NV.lnk, but manual execution of the hidden file BOOM.exe also results in the infection of the system. The individual contents of each file are detailed below.
The use of ISO as a vessel for malicious payloads is further notable due to the lack of mark of the web propagation on the contents, which may impact both host-based detections and reduce friction to user interaction with the contents.
The hidden NV directory in the mounted ISO contains a decoy PDF file named NV.pdf which contains a decoy advisory:
As described later in this analysis, the contents of the NV directory are displayed to the user by BOOM.exe.
NV.lnk is a shortcut/launcher for the hidden file BOOM.exe. As shown below, the shortcut leverages a living-off-the-land binary (LOLBin) and technique to proxy the execution of BOOM.exe using the following hardcoded shortcut target value: C:\Windows\System32\rundll32.exe c:\windows\system32\advpack.dll,RegisterOCX BOOM.exe.
Note that Microsoft also saw a variation of this LNK file containing the following shortcut target value: C:\Windows\System32\cmd.exe /c start BOOM.exe.
Numerous other LNKs were identified and are referenced in the appendix linked in this post. Methodologies varied, as did metadata in the LNKs themselves. For instance, the sample with the SHA-256: 48b5fb3fa3ea67c2bc0086c41ec755c39d748a7100d71b81f618e82bf1c479f0 contained a target of “%windir%/system32/explorer.exe Documents.dll,Open”, while the absolute path in the sample was “C:\Windows\system32\rundll32.exe”.
As referenced in Volexity’s blog post on the latest campaign, the LNK metadata was widely removed, and what remained varied between waves. Icons were often folders, meant to trick targets into thinking they were opening a shortcut to a folder.
Microsoft also observed the following targets for known LNK files:
BOOM.exe, tracked by Microsoft as “BoomBox”, can be best described as a malicious downloader. The downloader is responsible for downloading and executing the next-stage components of the infection. These components are downloaded from Dropbox (using a hardcoded Dropbox Bearer/Access token).
When executed, BoomBox ensures that a directory named NV is present in its current working directory; otherwise it terminates. If the directory is present, BoomBox displays the contents of the NV directory in a new Windows Explorer window (leaving it up to the user to open the PDF file).
Next, BoomBox ensures that the following file is not present on the system (if so, it terminates): %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll (this file is covered later in this analysis). BoomBox performs enumeration of various victim host qualities, such as hostname, domain name, IP address, and username of the victim system to compile the following string (using example values):
Next, BoomBox AES-encrypts the host information string above using the hardcoded encryption key “123do3y4r378o5t34onf7t3o573tfo73” and initialization vector (IV) value “1233t04p7jn3n4rg”. To masquerade the data as contents of a PDF file, BoomBox prepends and appends the magic markers for PDF to the AES-encrypted host information string above:
BoomBox proceeds to upload the data above (masquerading as a PDF file) to a dedicated-per-victim-system folder in Dropbox. For demonstration purposes, an example HTTP(s) POST request used to upload the file/data to Dropbox is included below.
To ensure the file has been successfully uploaded to Dropbox, BoomBox utilizes a set of regular expression values to check the HTTP response from Dropbox. As shown below, the regular expressions are used to check the presence of the is_downloadable, path_lower, content_hash, and size fields (not their values) in the HTTP response received from Dropbox. Notably, BoomBox disregards the outcome of this check and proceeds, even if the upload operation is unsuccessful.
Next, BoomBox downloads an encrypted file from Dropbox. For demonstration purposes, an example HTTP(s) POST request used to download the encrypted file from Dropbox is shown below.
After successfully downloading the encrypted file from Dropbox, BoomBox discards the first 10 bytes from the header and 7 bytes from the footer of the encrypted file, and then AES-decrypts the rest of the file using the hardcoded encryption key “123do3y4r378o5t34onf7t3o573tfo73” and IV value “1233t04p7jn3n4rg”. BoomBox writes the decrypted file to the file system at %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll. It then establishes persistence for NativeCacheSvc.dll by creating a Run registry value named MicroNativeCacheSvc:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicroNativeCacheSvc
The Run registry value is populated with the following command, which is used to execute NativeCacheSvc.dll using rundll32.exe and by calling its export function named “_configNativeCache”:
rundll32.exe %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll _configNativeCache
Next, BoomBox downloads a second encrypted file from the Dropbox path /tmp/readme.pdf, discards the first 10 bytes from the header and 7 bytes from the footer of the encrypted file, and then AES-decrypts the rest of the file (using the same AES IV and key as above). It writes the decrypted file at %AppData%\SystemCertificates\CertPKIProvider.dll and proceeds to execute the previously dropped file NativeCacheSvc.dll using the same rundll32.exe command as above.
As the final reconnaissance step, if the system is domain-joined, BoomBox executes an LDAP query to gather data such as distinguished name, SAM account name, email, and display name of all domain users via the filter (&(objectClass=user)(objectCategory=person)).
The enumerated data is AES-encrypted (using the same IV and key as before), encapsulated in a fake PDF file (as previously described), and uploaded to the Dropbox path /new/<Victim_ID>, where <Victim_ID> is the MD5 hash of the victim’s system name, for example: /new/432B65EF29F84E6043A80C15EBA12FD2.
NativeCacheSvc.dll, tracked by Microsoft as “NativeZone” can best be described as a malicious loader responsible for utilizing rundll32.exe to load the malicious downloader component CertPKIProvider.dll.
The malicious functionality of NativeCacheSvc.dll is located inside a DLL export named configNativeCache.
As shown above, the export function executes rundll32.exe to load %AppData%\SystemCertificates\Lib\CertPKIProvider.dll by calling its export function named eglGetConfigs.
CertPKIProvider.dll, tracked by Microsoft as “VaporRage” can best be described as a shellcode downloader. This version of VaporRage contains 11 export functions including eglGetConfigs, which houses the malicious functionality of the DLL.
As mentioned in the previous section, NativeZone utilizes rundll32.exe to execute the eglGetConfigs export function of CertPKIProvider.dll. Upon execution, the export function first ensures the NativeZone DLL %AppData%\Microsoft\NativeCache\NativeCacheSvc.dll is present on the system (else it terminates). Next, the export function issues an HTTP(s) GET request to a legitimate but compromised WordPress site holescontracting[.]com. The GET request is comprised of the dynamically generated and hardcoded values, for example:
The purpose of the GET request is to first register the system as compromised and then to download an XOR-encoded shellcode blob from the WordPress site (only if the system is of interest to the actor). Once successfully downloaded, the export function XOR decodes the shellcode blob (using a hardcoded multi-byte XOR key “346hrfyfsvvu235632542834”).
It then proceeds to execute the decoded shellcode in memory by jumping to the beginning of the shellcode blob in an executable memory region. The download-decode-execute process is repeated indefinitely, approximately every hour, until the DLL is unloaded from memory. VaporRage can execute any compatible shellcode provided by its C2 server, including a Cobalt Strike stage shellcode.
Additional Custom Cobalt Strike loader from NOBELIUM
As described in a previous blog, NOBELIUM has used multiple custom Cobalt Strike Beacon loaders (likely generated using custom Artifact Kit templates) to enable their malicious activities. These include TEARDROP, Raindrop, and other custom loaders.
Since our last publication, we have identified additional variants of NOBELIUM’s custom Cobalt Strike loaders. Instead of assigning a name to each short-lived and disposable variant, Microsoft will be tracking NOBELIUM’s custom Cobalt Strike loaders and downloaders for the loaders under the name NativeZone. As seen in previous custom NOBELIUM Cobalt Strike loaders, the new loader DLLs also contain decoy export names and function, as well as code and strings borrowed from legitimate applications.
The new NativeZone loaders can be grouped into two variants:
In the succeeding sections, we discuss some of the new NativeZone Cobalt Strike Beacon variants we have observed in our investigation.
NativeZone variant #1
Similar to the previous NOBELIUM custom Cobalt Strike loaders, such as TEARDROP and Raindrop, these NativeZone loaders are responsible for decoding/decrypting an embedded Cobalt Strike Beacon stage shellcode and executing it in memory. Some of the NativeZone loaders feature anti-analysis guardrails to thwart analysis of the samples.
In these versions of NativeZone, the actor has used a variety of encoding and encryption methodologies to obfuscate the embedded shellcode. For example, in the example below, the NativeZone variant uses a simple byte-swap decoding algorithm to decode the embedded shellcode:
Another sample featuring a different decoding methodology to decode the embedded shellcode is shown below:
Another sample, featuring a de-obfuscation methodology leveraging AES encryption algorithm to decrypt the embedded shellcode, is shown below:
Yet another NativeZone sample leveraging AES for decrypting an embedded Cobalt Strike shellcode blob is shown below (note the syntax differences compared to the sample above):
Another sample featuring a different decoding methodology along with leveraging CreateThreadpoolWait() to execute the decoded shellcode blob is below:
Below is an example of anti-analysis technique showing the loader checking if the victim system is a Vmware or VirtualBox VM:
NativeZone variant #2
Unlike variant #1, the NativeZone variant #2 samples do not contain the encoded/encrypted Cobalt Strike Beacon stage shellcode. Instead, these samples read the shellcode from an accompanying file that is shipped with the sample. For example, one NativeZone variant #2 sample was observed alongside an RTF file. The RTF file doubles as both a decoy document and a shellcode carrier file. The RTF file contains the proper RTF file structure and data followed by an encoded shellcode blob (starting at offset 0x658):
When the NativeZone DLL is loaded/executed, it first displays the RTF document to the user.
As mentioned above, the same RTF also contains the encoded Cobalt Strike stage shellcode. As shown below, the NativeZone DLL proceeds to extract the shellcode from the RTF file (starting at file offset 0x658 as shown above), decode the shellcode and execute it on the victim system:
Notes on new and old NOBELIUM PDB paths
The following example PDB paths were observed in the samples analyzed in this blog:
Note the presence of ‘dev’ user in the PDB paths above. A ‘dev’ username was previously observed in the PDB path of a NOBELIUM Cobalt Strike loader mentioned in our previous blog: c:\build\workspace\cobalt_cryptor_far (dev071)\farmanager\far\platform.concurrency.hpp.
The sophisticated NOBELIUM attack requires a comprehensive incident response to identify, investigate, and respond. Get the latest information and guidance from Microsoft at https://aka.ms/nobelium.
Microsoft Defender Antivirus
Microsoft Defender Antivirus detects the new NOBELIUM components discussed in this blog as the following malware:
Microsoft Defender for Endpoint (EDR)
Alerts with the following titles in the Security Center can indicate threat activity on your network:
The following alerts might also indicate threat activity associated with this threat, but they can also be triggered by unrelated threat activity:
Azure Sentinel
We have updated the related Azure Sentinel query to include these additional indicators. Azure Sentinel customers can access this query in this GitHub repository.
The NOBELIUM IOCs associated with this activity are available in CSV on the MSTIC GitHub.
Microsoft Threat Intelligence Center (MSTIC) has uncovered a wide-scale malicious email campaign operated by NOBELIUM, the threat actor behind the attacks against SolarWinds, the SUNBURST backdoor, TEARDROP malware, GoldMax malware, and other related components. The campaign, initially observed and tracked by Microsoft since January 2021, evolved over a series of waves demonstrating significant experimentation.
Microsoft has identified three new pieces of malware being used in late-stage activity by NOBELIUM – the actor behind the SolarWinds attacks, SUNBURST, and TEARDROP.
Our continued investigation into the Solorigate attack has uncovered new details about the handover from the Solorigate DLL backdoor (SUNBURST) to the Cobalt Strike loader (TEARDROP, Raindrop, and others).
Since October 22, 2024, Microsoft Threat Intelligence has observed Russian threat actor Midnight Blizzard sending a series of highly targeted spear-phishing emails to individuals in government, academia, defense, non-governmental organizations, and other sectors. This activity is ongoing, and Microsoft will continue to investigate and provide updates as available. Based on our investigation of previous Midnight […]
